This page is a new take on the concept of "virtual platforms", which are
platforms that do not (necessarily) have a real java agent running on them
One example could be a RHEL 7 server with a CIMOM, where the CIMOM provides the agent functionality and talks with RHQ over the RHQ REST-interface
See also Needed: pseudo platforms and especially Design - Agentless management.
In a more virtual environment, installing a java-agent on each machine is consuming a lot of resources - especially on virtual guests. The current model allows via libvirt plugin to monitor some of the guest's platform, but does not go any further for any server processes inside the virtual guest; also such processes would show up as children of the base platform and not of the virtual children.
In scenarios like the above where already other mechanisms are used for monitoring, running a java agent in addition is not very accepted by customers.
Sometimes there are even scenarios where an application itself wants to send e.g. usage metrics via the REST interface. The application may even run on a process (e.g. application server) on a physical platform with a java agent, but does not have a full fledged agent plugin and/or way of exposing the data in a manner where an agent plugin can pull it from. See e.g. Monitoring the Monster
Right now, it is required to have an agent on a platform - a platform resource on its own just does not work.
The REST-API allows to create platforms and resources on this platform. In order to get this to work, a "dummy agent" is created. This works relatively well especially when the resources like he above ticket monster app are pushing metrics when they see fit.
Unfortunately removing the platform or any of the resources below it (e.g. via the rest-interface) will result in a nasty exception, as the server tries to run the "uninventory" on the agent, but as there is no valid agent client present this is failing.
The following is a (probably incomplete) list of options we could follow - this is no either/or list btw.
This would remove the requirement for a platform to have an agent. This would probably require checks in many places and also break many assumptions we have in the code.
One could perhaps also flag the platform as "virtual" and check for this flag instead of checking for a null agent. Unfortunately this would impact the resource table, which is already big and which has an impact of all (potentially 100k+) resources in the table and should be carefully analyzed for performance hits.
Here the agent gets a flag that it is a synthetic one. This also creates a special AgentClient, that does not try to talk to a real agent.
While I first thought that a binary flag ("is_synthetic") is enough, I can now imagine that an enum ("agent_kind") is more suited, as this would allow to have a purely synthetic one like what we have with the current (as of 2013-3-15) REST-api or one where the "managed resource" has registered callbacks or one which is using long-poll / websockets.
Our domain model already allows to nest platforms and this is matching with a more virtual world, where on has a base platform with many virtual guests.
Currently those virtual platforms show up next to other platforms without any "link" to the parent. And if the availability of the parent goes down (machine crashes, is shut down), the availability of the children is not automatically honored.